• I have signed the Contributor License Agreement.
• I have updated the Release Notes.
• This pull request is related to an issue.
  • Resolves [Sandbox Test]: WinGet failed to download installer file with proper name #6121
  • Resolves Installer downloaded successfully and exists on disk, but installation phase fails/silently exits #6126

Fix MOTW security check failures for downloaded installers

Problem

All installer downloads were failing the security check with 0x80070003 (ERROR_PATH_NOT_FOUND), causing every install to terminate with "Installer failed security check".

Two root causes were identified:

• Wrong file scanned by IAttachmentExecute — UpdateInstallerFileMotwIfApplicable ran before RenameDownloadedInstaller in the workflow. This meant the Attachment Execution Service (AES) was scanning the
  temporary pre-hash-validation file (a raw SHA256 hex string with no extension, e.g. aab2dc8e…) rather than the final installer (e.g. BadlionClient.exe).

• RemoveMotwIfApplicable failures aborted the security check — If removing the existing Zone.Identifier ADS failed, the exception propagated through the AES thread, leaving IAttachmentExecute::Save() never
  called and the whole check returning a failure code. Additionally, a missing THROW_IF_FAILED(hr) after IPersistFile::Load meant unexpected load errors were silently ignored, leading to Remove()/Save()
  being called on a non-loaded object.

Changes

DownloadFlow.cpp

• Reorder workflow: RenameDownloadedInstaller now runs before UpdateInstallerFileMotwIfApplicable, so AES always scans the properly-named installer file.

Downloader.cpp — RemoveMotwIfApplicable

• Also handle ERROR_PATH_NOT_FOUND (in addition to ERROR_FILE_NOT_FOUND) from IPersistFile::Load — different Windows builds return different codes when no Zone.Identifier ADS is present.
• Restore missing THROW_IF_FAILED(hr) to correctly surface any other Load failures rather than falling through to Remove()/Save() on an unloaded object.

Downloader.cpp — ApplyMotwUsingIAttachmentExecuteIfApplicable

• Wrap RemoveMotwIfApplicable in a try/catch inside the updateMotw lambda — log a warning but proceed to IAttachmentExecute::Save(). MOTW removal is best-effort; a removal failure should not abort the
  security scan.
• Wrap the entire AES thread body in try/catch and log exceptions via AICLI_LOG, so unhandled errors are surfaced rather than silently leaving hr in an indeterminate state. Use LOG_IF_FAILED for
  CoInitializeEx so failures are captured through WIL.
• Fix the return value: previously aesSaveResult was always returned, reporting S_OK when Save() was never reached (e.g. after CoInitializeEx failure). Now returns the thread's hr when aesSaveResult was
  never updated

Microsoft Reviewers: Open in CodeFlow